home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1195 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.5 KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: Digest
  3. Date:     Sun, 31 Jul 1994 06:30:08 -0600
  4. Precedence: bulk
  5.  
  6. [This is a digested reply.]
  7.  
  8. Timothy -> Ken:
  9. >And you're not reading what I said either.  I said, "I will soon for the
  10. >sake of knowing it."
  11.  
  12. I have no clue what WF_BEVENT is.  I'll look in the Compendium.
  13.  
  14. Timothy -> Ken:
  15. >And you have no right to question my credibility as a GEM programmer.
  16.  
  17. Ken/Dan (whichever) has questioned the competence of at least six
  18. programmers on this list.  Usually the person he is arguing with at
  19. the time becomes the victim...  There is not much to being a GEM
  20. programmer.  If you follow the rules (use the event-driven model) and
  21. do not deviate from the existing standard (or guidelines) then that
  22. seems sufficient to me.  It does not say anywhere that you have to
  23. agree with Kan (Ken + Dan = Kan) to be a good programmer.
  24.  
  25. Kan -> Timothy:
  26. >The "most elegant" to me sounds like "the laziest". I.e. put the least
  27. >amount of effort in doing something. If you're going to do something, why
  28. >not spend the time doing it RIGHT? Rather than a half-hearted attempt at
  29. >doing the bare minimum?
  30.  
  31. Kan (this is the name I intend to keep using; it is much easier than
  32. typing Ken/Dan -- no need to take it as an insult, because it is not),
  33. the most elegant solution can mean many things.  It could be the fastest,
  34. or the smallest, or the easiest to read, or any combination of those.  It
  35. is different for every programmer and every application.  In my case, the
  36. most elegant solution is a combination.  My point is that it is a different
  37. issue for everyone.  Since you do not know Timothy, calling him lazy,
  38. stupid, ignorant, peasant-like, foolish, or anything else is really a
  39. meaningless thing to do.
  40.  
  41. Timothy -> Ken:
  42. >Once again, you are twisting the facts.  I go for SIMPLE.  You know...
  43. >keep it simple, stupid!  The less code, the less likely is one to find a
  44. >bug.  The more modular your code is the easier it is to test in parts,
  45. >and the more intellegently you use that modularity, the smaller you code
  46. >will be.
  47.  
  48. All true; I am not great at writing completely self-contained modules (so
  49. that they can be tested independantly of the rest of the program).  It
  50. would be handy to be able to do so, though...  :)
  51.  
  52. >On the other hand, if you don't change it, people WILL notice because
  53. >they'll be losing a lot of data.
  54.  
  55.  
  56. -- 
  57. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca    //
  58. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca               //
  59. PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 AD 6E 02 71 85
  60.